home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Paste Exception.3 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.1 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Paste Exception
  2. Sent:        6/11/96 3:32 PM
  3. Received:    6/11/96 3:52 PM
  4. From:        Mark Lanett, mlanett@meer.net
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >>Putting up the dialog at the point where you detect the error may not be
  9. >>best (especially if you are in the middle of a drag), but I don't know of
  10. >>any clean way to throw an exception and put up an alert afterwards. Perhaps
  11. >>you could set something up with idling.
  12. >
  13. >How does ODF handle the case where an exception from, say a memory
  14. >allocation failure, happens in the subclass of FW_CContent::Internalize
  15. >that had been called because of a drop? Something does put up a dialog,
  16. >right?
  17.  
  18. All we ever do is throw an ODException*, which is a single integer.
  19. Exceptions from all parts eventually wind their way up the stack back to
  20. the OpenDoc event handler, which looks up the error code in its string
  21. table and displays a dialog. Only the standard error codes have strings;
  22. there is no way that I know of to supply your own. There is also no way to
  23. supply parameters.
  24.  
  25. ODF's additional error codes have been assigned a range by Apple, but I
  26. don't actually know if we get user strings also, and again, you can't have
  27. pass parameters.
  28.  
  29. What it comes down to is that for now you have to put up your own dialog
  30. and then throw an exception. This seems simple but isn't, because of cases
  31. like drag&drop, or perhaps your caller intended to catch any exception you
  32. threw and work around it without needing an alert dialog. The first case
  33. can be handled by putting up your alert when your Idle gets called (instead
  34. of at the error time), but for the second case... there is no way for you
  35. to know if your caller intended to supress your exceptions.
  36.  
  37. *Actually we throw C++ FW_XException objects, which are converted to
  38. ODException when we return across the SOM boundary. This is way there's no
  39. real advantage to defining your own exception, since the non-OD-error-code
  40. portion will be lost.
  41.  
  42.  
  43. --
  44. Mark Lanett, OpenDoc Framework, Apple Computer
  45.  
  46.